Ban database refactor#42495
Merged
PJB3005 merged 22 commits intospace-wizards:stablefrom Jan 23, 2026
Merged
Conversation
Supports all the new functionality (multiple players/addresses/hwids/roles/rounds per ban).
The server ID check is no longer done as admins may want to place bans spanning multiple rounds irrelevant of the source server.
PJB3005
added
P2: Raised
PJBot
added
S: Approved
Member
Author
|
Marking as draft since I still want to do more testing. Also I need to rebase this onto stable so we can do the server update. |
PJBot
added
Changes: Sprites
PJB3005
force-pushed
the
26-01-16-ban-db-refactor
branch
from
f637bb8 to
390d7f2
Compare
PJBot
removed
Changes: Map
Not relevant, reduces query performance
Would blow up handling null player records. Not a new bug introduced by the refactor, but I ran into it.
Member
VasilisThePikachu
left a comment
VasilisThePikachu
left a comment
There was a problem hiding this comment.
I will do a review later however quick thing I noticed
Please update the deletion and data dump scripts to the new schema.
Member
Author
oh yeah fair enough |
VasilisThePikachu
approved these changes
Jan 21, 2026
juliangiebel
requested changes
Jan 21, 2026
PJBot
added
S: Awaiting Changes
Contributor
|
The schema looks fine otherwise. The queries could be improved to cut down on roundtrips (because of split queries. The ban table really isn't large enough to require split queries imo) and joins but that is really out of scope for this PR imo |
Most notably happened with role bans, as multiple departments may include the same role.
PJBot
added
S: Needs Review
juliangiebel
approved these changes
Jan 21, 2026
VasilisThePikachu
added
the
S: DO NOT MERGE
Member
|
Merge before maintenance starts so that vulture does not start with it before we are ready for the db migration. |
github-project-automation
bot
moved this from 👀 Needs Review
to ✅ Done
in NextGen WizDen Adminning
PJB3005
added a commit
that referenced
this pull request
Jan 23, 2026
Ban database refactor (#42495) * Ban DB refactor seems to work at a basic level for PostgreSQL * New ban creation API Supports all the new functionality (multiple players/addresses/hwids/roles/rounds per ban). * Make the migration irreversible * Re-implement ban notifications The server ID check is no longer done as admins may want to place bans spanning multiple rounds irrelevant of the source server. * Fix some split query warnings * Implement migration on SQLite * More comments * Remove required from ban reason SS14.Admin changes would like this * More missing AsSplitQuery() calls * Fix missing ban type filter * Fix old CreateServerBan API with permanent time * Fix department and role ban commands with permanent time * Re-add banhits navigation property Dropped this on accident, SS14.Admin needs it. * More ban API fixes. * Don't fetch ban exemption info for role bans Not relevant, reduces query performance * Regenerate migrations * Fix adminnotes command for players that never connected Would blow up handling null player records. Not a new bug introduced by the refactor, but I ran into it. * Great shame... I accidentally committed submodule update... * Update GDPR scripts * Fix sandbox violation * Fix bans with duplicate info causing DB exceptions Most notably happened with role bans, as multiple departments may include the same role.
PJB3005
added a commit
that referenced
this pull request
Jan 23, 2026
Ban database refactor (#42495) * Ban DB refactor seems to work at a basic level for PostgreSQL * New ban creation API Supports all the new functionality (multiple players/addresses/hwids/roles/rounds per ban). * Make the migration irreversible * Re-implement ban notifications The server ID check is no longer done as admins may want to place bans spanning multiple rounds irrelevant of the source server. * Fix some split query warnings * Implement migration on SQLite * More comments * Remove required from ban reason SS14.Admin changes would like this * More missing AsSplitQuery() calls * Fix missing ban type filter * Fix old CreateServerBan API with permanent time * Fix department and role ban commands with permanent time * Re-add banhits navigation property Dropped this on accident, SS14.Admin needs it. * More ban API fixes. * Don't fetch ban exemption info for role bans Not relevant, reduces query performance * Regenerate migrations * Fix adminnotes command for players that never connected Would blow up handling null player records. Not a new bug introduced by the refactor, but I ran into it. * Great shame... I accidentally committed submodule update... * Update GDPR scripts * Fix sandbox violation * Fix bans with duplicate info causing DB exceptions Most notably happened with role bans, as multiple departments may include the same role.
ThatGuyUSA
pushed a commit
to ThatGuyUSA/space-station-14
that referenced
this pull request
Feb 3, 2026
Ban database refactor (space-wizards#42495) * Ban DB refactor seems to work at a basic level for PostgreSQL * New ban creation API Supports all the new functionality (multiple players/addresses/hwids/roles/rounds per ban). * Make the migration irreversible * Re-implement ban notifications The server ID check is no longer done as admins may want to place bans spanning multiple rounds irrelevant of the source server. * Fix some split query warnings * Implement migration on SQLite * More comments * Remove required from ban reason SS14.Admin changes would like this * More missing AsSplitQuery() calls * Fix missing ban type filter * Fix old CreateServerBan API with permanent time * Fix department and role ban commands with permanent time * Re-add banhits navigation property Dropped this on accident, SS14.Admin needs it. * More ban API fixes. * Don't fetch ban exemption info for role bans Not relevant, reduces query performance * Regenerate migrations * Fix adminnotes command for players that never connected Would blow up handling null player records. Not a new bug introduced by the refactor, but I ran into it. * Great shame... I accidentally committed submodule update... * Update GDPR scripts * Fix sandbox violation * Fix bans with duplicate info causing DB exceptions Most notably happened with role bans, as multiple departments may include the same role.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
About the PR
This refactors the way bans are stored in the database, enabling bans to have multiple players/HWIDs/IPs/rounds/roles per ban. There's also significant code cleanup along the way.
This PR does not update most of the game/tooling to expose this new functionality (eg banning on multiple round IDs), that can be done in separate PRs once the main schema refactor is over with. The one exception is that role bans now make one ban with multiple roles.
Why / Balance
Our admins are weeping because role bans weren't normalized in the DB properly and needed to be separate records per job.
Having multiple players/HWIDs/IPs per ban record enables future sticky ban tracking systems sanely.
Multiple rounds per ban is because I was thinking "well if I'm gonna do a massive DB change might as well be proactive."
Technical details
The DB model has been significantly refactored:
typecolumn on the singlebantable.ProtoId<>more thoroughly in some role ban code.Job:Captain) are now more cleanly typed to avoid confusion.Media
Requirements
Breaking changes
ServerBanDef&ServerRoleBanDef->BanDef).GetBanAsync().ProtoId<>more thoroughly in some role ban code.Job:Captain) are now more cleanly typed asBanRoleDefin C# to avoid confusion.Changelog
🆑
ADMIN: